Technical Field
The disclosed technology relates to the field of Remote Procedure Call (RPC) technology used by computer procedures that are executed by one or more computers.
Background Art
Traditional RPC technology enables one program (the RPC client) to invoke a procedure that is executed by a server program (the RPC server) to provide a service. The RPC client and RPC server often, but need not, execute on different computers connected by a network (for example, the Internet).
At a high level of abstraction and within a standard Object Oriented Programming (OOP) framework, traditional RPC operates by executing methods provided by one or more global objects at the RPC server. When executed, the methods in these global objects provide services for the RPC client. One goal of traditional RPC is to allow a procedure executing on the same computer as the RPC client to invoke object methods to perform services without the procedure being aware of whether the service is provided through local execution of the method providing the service, or whether the service is performed through remote execution of the method providing the service. Thus, the Application Programming Interface (API) for the service is independent of whether the service is executed locally or remotely.
The RPC client program can use one or more stub objects that have a one-to-one relationship with the services provided by the RPC server. Both the RPC server and RPC client often include ancillary procedures that are used by the RPC server and RPC client to provide necessary communication and coordination facilities.
When the RPC client program invokes a method of a stub object, the stub object assembles the parameters passed to the method into a message and identifies the corresponding object on the RPC server. An interface description language (IDL) can be used to assemble the message (for example into XML, JSON, etc.). The message is sent to a server stub that extracts the message (thus, generating parameters that are to be passed to the specified method of the identified object on the RPC server). The RPC server executes the method and returns a result (in a similar manner) to the RPC client stub that, in turn, can return the result to the RPC client program in accordance with the API for the executed method.
Traditional RPC can also be implemented using a prototypal language (such as JavaScript). Traditional RPC including callbacks and their use.
In prior traditional RPC, there is a static association between the RPC client request and an operation on the RPC server as well as with the callback on the RPC client invoked by the RPC server. RPC communication can be programmed as a synchronous operation (the RPC client program requests a service from the RPC server and waits until that requested service completes) or as an asynchronous operation (where the RPC client program requests a service from the RPC server and then continues processing). The RPC server can invoke the callback on the RPC client at later time.
Previous object-based traditional RPC protocols use static functions normally identified by name. The RPC client cannot easily modify functions provided by the RPC server while the RPC client and the RPC server are communicating. Furthermore, the RPC client cannot directly use object instances at the RPC server. Finally, the RPC client cannot submit programming language statements (client-specified statements) to the RPC server for execution on the RPC server. Some RPC server JavaScript implementations can replace functions (for example, by downloading and using script tags etc.). However, in these implementations, the replaced functions are still static functions identified by name; and the RPC server is inactive while the functions are being replaced.
It would be advantageous to have an RPC client that can define new services or modify existing services provided by an RPC server dynamically such that those new/modified services can be immediately accessed in real-time. It would also be advantageous for the RPC client (or RPC server) to construct and use object instances on the RPC server. It would also be advantageous to expand the callback functionality beyond that provided by traditional RPC. In addition, it would be advantageous for an RPC client to direct a RPC server to execute client-specified statements.